The Mythical Man-Month: Essays on Software Engineering
- Downloads：7805
- Type：Epub+TxT+PDF+Mobi
- Create Date：2021-07-09 08:55:23
- Update Date：2025-09-06
- Status：finish
- Author：Frederick P. Brooks Jr.
- ISBN：0201835959
- Environment：PC/Android/iPhone/iPad/Kindle
- Download
Summary
Few books on software project management have been as influential and timeless as The Mythical Man-Month。 With a blend of software engineering facts and thought-provoking opinions， Fred Brooks offers insight for anyone managing complex projects。 These essays draw from his experience as project manager for the IBM System/360 computer family and then for OS/360， its massive software system。 Now， 45 years after the initial publication of his book， Brooks has revisited his original ideas and added new thoughts and advice， both for readers already familiar with his work and for readers discovering it for the first time。
The added chapters contain （1） a crisp condensation of all the propositions asserted in the original book， including Brooks' central argument in The Mythical Man-Month: that large programming projects suffer management problems different from small ones due to the division of labor; that the conceptual integrity of the product is therefore critical; and that it is difficult but possible to achieve this unity; （2） Brooks' view of these propositions a generation later; （3） a reprint of his classic 1986 paper "No Silver Bullet"; and （4） today's thoughts on the 1986 assertion， "There will be no silver bullet within ten years。"
Reviews
Martin Mihaylov
，
An old-timer， classic book for software development。 Some of the principles have changed a bit， but most of them are still valid。
Gustavo
，
Vale como registro histórico。 Algumas passagens ainda são válidas。Estilo de escrita um tanto quanto maçante， empolado。
Kiril Kirilov
，
“Thou shall not estimate in man-months because they are not interchangeable。" “Thou shall not estimate in man-months because they are not interchangeable。" 。。。more
Derek
，
9 women can't work together to have a baby in 1 month。Adding workers to a non-systemized project increases manhours and delays release。 9 women can't work together to have a baby in 1 month。Adding workers to a non-systemized project increases manhours and delays release。 。。。more
nixitN
，
{ 4。5 stars } This book isn't a modern edition， but it contains a lot of useful information that a programmer needs to know。 What a programmer can use in real life。 To group work， at a company， even as an individual。 So it convinced me and this book gave me self-confidence as well。 It’s finally a book that inspires me and doesn’t fill my mind with codes， but mental gives strength to self-learning。 { 4。5 stars } This book isn't a modern edition， but it contains a lot of useful information that a programmer needs to know。 What a programmer can use in real life。 To group work， at a company， even as an individual。 So it convinced me and this book gave me self-confidence as well。 It’s finally a book that inspires me and doesn’t fill my mind with codes， but mental gives strength to self-learning。 。。。more
Damien Sulla-Menashe
，
This was an interesting read about the history and traditions of software design from the 70s to the 90s。 The author synthesizes work originally from 1975 with essays from 1986 and 1995。 The 20 year journey distills certain truisms about the effort and discipline of engineering software。 The major focus is on how to manage people and how engineers can work well in a large company as part of a bigger team。 I found some of these lessons to be very enlightening on managing time， writing documentati This was an interesting read about the history and traditions of software design from the 70s to the 90s。 The author synthesizes work originally from 1975 with essays from 1986 and 1995。 The 20 year journey distills certain truisms about the effort and discipline of engineering software。 The major focus is on how to manage people and how engineers can work well in a large company as part of a bigger team。 I found some of these lessons to be very enlightening on managing time， writing documentation， and the inherent complexity in writing code。 Having been stitched together from multiple parts in what is now ancient history of the computer， there's a lot of understandable misses by the author。 That he couldn't predict the Cloud and the birth of well managed open source programs is not a criticism， he is not a prophet。 He does lay out a point by point summary of the work and this is a really nice feature。 Others will point out that his software engineer is always a white cis male but I don't think he is being intentionally sexist， that is more a sign of the times。 I wish he could have talked more about the invention of git-based version control because he discusses code versioning in lots of places but this just shows how much the internet has been a game changer。 In the end the web was that silver bullet that came in 25 years not 10。 。。。more
Alfred Nash
，
A classic
Eric
，
Good ideas but everything is a bit dated。 The big picture is still relevant， but that picture has already been incorporated in modern development practices， for instance every engineering manager already knows the risk that adding more people can slow things down。A lot of development practices just seem dated。 The way he suggests teams be structured would seemingly break apart with the turnover of a modern startup。 Strict encapsulation and clear APIs trotted by OOO is really expensive to maintai Good ideas but everything is a bit dated。 The big picture is still relevant， but that picture has already been incorporated in modern development practices， for instance every engineering manager already knows the risk that adding more people can slow things down。A lot of development practices just seem dated。 The way he suggests teams be structured would seemingly break apart with the turnover of a modern startup。 Strict encapsulation and clear APIs trotted by OOO is really expensive to maintain for most software that needs to maintain decent velocity （or doesn't have much resources）。 A lot of the examples involve procedures that implement algorithms， when that's very little of modern code。 Not to say I couldn't imagine a modern software project being successful implementing these things， but it would be a different type of product than I've worked on （mostly web applications）。 。。。more
Hadi
，
Simply a classic！
Zhenia Vasiliev
，
Not the first time I engage with this book， but happy that I finally had a chance to read it。 Five stars does not of course mean that I entirely agree with what the book says， or that its practical technical matters are entirely applicable today， but rather that it is understandable， speaks to the point， relevant to my interests and a joy to read。
Victor Hom
，
some good points made but hard to find。 it does make you think about the team formation for projects and how it relates to the examples given （note that this book is from 1975）there's a chapter at the end on the author's thoughts after 20 years， where Brooks shows humility in areas that he got wrong。 some good points made but hard to find。 it does make you think about the team formation for projects and how it relates to the examples given （note that this book is from 1975）there's a chapter at the end on the author's thoughts after 20 years， where Brooks shows humility in areas that he got wrong。 。。。more
Leandro Melendez
，
Estuve tentado a darle 3 estrellas a esta obra maestra， debido a que algo de el contenido ya se siente viejo， pues habla de sistemas que ya pasaron a la historia。Pero despues me dije， es un libro de hace casi 50 años！Y con todo eso， es sobresaliente que muchos de los problemas que describe， son aun relevantes y tristemente， todavia un dolor de cabeza para muchos proyectos。En español creo que nos referimos mas a Hora-Hombre， pero el punto es algo muy basico de la historia de los proyectos donde s Estuve tentado a darle 3 estrellas a esta obra maestra， debido a que algo de el contenido ya se siente viejo， pues habla de sistemas que ya pasaron a la historia。Pero despues me dije， es un libro de hace casi 50 años！Y con todo eso， es sobresaliente que muchos de los problemas que describe， son aun relevantes y tristemente， todavia un dolor de cabeza para muchos proyectos。En español creo que nos referimos mas a Hora-Hombre， pero el punto es algo muy basico de la historia de los proyectos donde se sigue pensando que con 9 mujeres se puede hacer un bebe en un mes。 Lo que no habia visto con otros autores y en otras obras， son los analisis en los impactos que conlleva administrar mas gente， y el cuello de botella donde administrar mas recursos para sacar algo a tiempo， puede tomar mas tiempo que el trabajo mismo。La frase que me encanto de un proyecto va algo asi como:Sacar a tiempo forzadamente un proyecto retrasado， es como un platillo cocinandose。。。 Si aun no está listo en el momento acordado， uno tiene 2 opciones， esperar un poco mas， o comer el platillo crudo。GENIAL！ 。。。more
Norent Khy
，
The author argues that the total of creative work cannot be estimated in the mythical man-month。 And he does so through his various essays on how to manage software development。It is an old book （especially in terms of software） that has aged well。 The author does not make outlandish claims， he develops his argumentation quite well。 It was nice to have it provoke my own critical thinking with regards to the process of software development， given how old the book is。
Teo Asinari
，
In summary 'muh conceptual unity' 。。。 at all costs。 Some interesting prose about why programming is interesting， as well as the 'surgeon' model for a programming team。 I have to wonder。。。 why isn't this model used in the industry at all？ Too much power in the hands of the 'surgeon' aka master chef aka non-superfluous entity？ In summary 'muh conceptual unity' 。。。 at all costs。 Some interesting prose about why programming is interesting， as well as the 'surgeon' model for a programming team。 I have to wonder。。。 why isn't this model used in the industry at all？ Too much power in the hands of the 'surgeon' aka master chef aka non-superfluous entity？ 。。。more
Daniela
，
Leitura complexa。 Pontos relevantes e atuais， muitas idéias realmente se concretizaram como o fato de que ferramentas iriam melhorar a performance e produtividade。O que achei mais interessante foi o fato de que a Engenharia de Software não foi criada levando em consideração a produtividade do desenvolvedor， e esse estudo é muito recente e relevante
Samin
，
Rating: 3。75This book is great to give a historical context of software engineering and to give insight into how practices we use today were established through trial and error。Some of the chapters did drag on a bit， mostly because they felt less relevant to the current state of the discipline today and due to some redundancy。 But， overall， still worth a read。Brooks gives interesting insight into the project management aspect of software and how it is essentially a field revolving around engagin Rating: 3。75This book is great to give a historical context of software engineering and to give insight into how practices we use today were established through trial and error。Some of the chapters did drag on a bit， mostly because they felt less relevant to the current state of the discipline today and due to some redundancy。 But， overall， still worth a read。Brooks gives interesting insight into the project management aspect of software and how it is essentially a field revolving around engaging teams and gives an exploration into the essentials of what software creation entails in its fundamental form。 。。。more
Ankit Agrawal
，
It is a really good book but with the advancement of the industry， its quite outdated now but the core principles are still relevant and still very much required to be learnt
肥啾 H
，
Absolutely love it！！ Miracle writer。 ✍️
Endre Kemenes
，
I cannot say I'm very impressed with this book。 It is really outdated and although I read the anniversary edition， which clarifies lots of outdated things that have changes meanwhile， it is not worth a read 15 chapters， so that in the additional 4 the author explains that he was wrong in so many things。 It is mainly based on waterfall software development and talks about issues （such as memory or disk space） that are not really relevant anymore。 I cannot say I'm very impressed with this book。 It is really outdated and although I read the anniversary edition， which clarifies lots of outdated things that have changes meanwhile， it is not worth a read 15 chapters， so that in the additional 4 the author explains that he was wrong in so many things。 It is mainly based on waterfall software development and talks about issues （such as memory or disk space） that are not really relevant anymore。 。。。more
Joshua R。 Taylor
，
Did not finish。Really struggled with this one。 It’s a really well known classic in the software world。 However I’m not finding much of what Brookes is conveying especially insightful in the current software climate。Perhaps if I become a project manager， I’ll return to it。 I would definitely recommend it to any project manager working in software （from what I read of it）。
Darragh
，
Probably great for it's time， but its style and thinking have been fairly superseded by other more relevant text and industry as a whole。 Probably great for it's time， but its style and thinking have been fairly superseded by other more relevant text and industry as a whole。 。。。more
Víctor Martínez
，
Ya hace medio siglo que se escribió este libro y aún algunos de sus mensajes siguen vigentes。 Lastimosamente la mayoría de los capítulos ya envejecieron y no aplican a la actualidad del desarrollo de software， lo que sigue siendo cierto es que aún la complejidad inherente a la transmisión de ideas entre el usuario y quien implementa （previo paso por el diseño del arquitecto） aún sigue generando dolores de cabeza。Respecto a la bala de plata que mejore la productividad del desarrollo de software y Ya hace medio siglo que se escribió este libro y aún algunos de sus mensajes siguen vigentes。 Lastimosamente la mayoría de los capítulos ya envejecieron y no aplican a la actualidad del desarrollo de software， lo que sigue siendo cierto es que aún la complejidad inherente a la transmisión de ideas entre el usuario y quien implementa （previo paso por el diseño del arquitecto） aún sigue generando dolores de cabeza。Respecto a la bala de plata que mejore la productividad del desarrollo de software yo creo que ya existe: agilismo y microservicios en un entorno en la nube。 La combinación de metodología y herramientas reduce enormemente la complejidad tanto esencial como accidental del desarrollo de software。 Es una lástima sin embargo que aún tanta empresas implementen el agilismo de mala forma。 。。。more
Batuhan
，
The main concept put here is the 'conceptual integrity'。 Different parts of the software must be written with respect to the same concept。 For example functional programming， or object oriented programming。Another thing the book stress is that the software is very communication intensive business。 When you are n people， you can communicate with n-1 people。 So communication web has O（n（n-1）/2） = O（n^2） complexity。 So more software engineers not allways means the shorter delivery time of the softw The main concept put here is the 'conceptual integrity'。 Different parts of the software must be written with respect to the same concept。 For example functional programming， or object oriented programming。Another thing the book stress is that the software is very communication intensive business。 When you are n people， you can communicate with n-1 people。 So communication web has O（n（n-1）/2） = O（n^2） complexity。 So more software engineers not allways means the shorter delivery time of the software。Great Book。 。。。more
Andrew Breza
，
The Mythical Man-Month was written before I was born yet it contains so much advice that's directly relevant to my job as a data scientist。 It's amazing how many of the same issues Brooks observed in 1975 are still prevalent today。 Throwing more people at a project and thinking output will increase linearly， moving forward with a project without sufficient planning， not communicating changes to a plan to everyone who needs to know， etc。 These issues are immediately recognizable to me in 2021。 Th The Mythical Man-Month was written before I was born yet it contains so much advice that's directly relevant to my job as a data scientist。 It's amazing how many of the same issues Brooks observed in 1975 are still prevalent today。 Throwing more people at a project and thinking output will increase linearly， moving forward with a project without sufficient planning， not communicating changes to a plan to everyone who needs to know， etc。 These issues are immediately recognizable to me in 2021。 This is a short book and it should be required reading for anybody who manages high-tech projects。 。。。more
Gaurav Srivastava
，
Dated。 Underwhelming。
Piotr Kafel
，
“Adding manpower to a late software project， makes it later。”First edition of this book was published in 1975。 The version that is available today is from 1995 and contains additional essays that discuss what has changed since the original book。 That means most of the content of this book is almost 50 years old。 Fantasy that is 50 years old could still be good but can a book about software engineering do the same？“For the human makers of things， the incompletenesses and inconsistencies of our id “Adding manpower to a late software project， makes it later。”First edition of this book was published in 1975。 The version that is available today is from 1995 and contains additional essays that discuss what has changed since the original book。 That means most of the content of this book is almost 50 years old。 Fantasy that is 50 years old could still be good but can a book about software engineering do the same？“For the human makers of things， the incompletenesses and inconsistencies of our ideas become clear only during implementation。”Content-wise the book is a mixture of technology from 70 and general approach to software engineering。 The essays that focus on problems present at the time of first publication are not that interesting and I have a feeling they often required a context for how computers worked back then。 That's maybe 30 - 40% of the book。 All the rest is pure gold。。。Starting with Brooks law and explanation for it through insides into accidental / essential complexity and ending up on predictions about the future the content is thought provoking。 During the read whenever I encountered a familiar situation I immediately had two thoughts - "Things didn't change that much '' and "They already knew about it in the 70's"。 Many books about software engineering that were published during last years are often more obsolete than this one。One more thing worth mentioning here is a style of writing。 For everybody who claims that there is nothing new in this book I would still recommend to read at least an essay or two。 The clarity of thoughts and preciseness of Brook's language is admirable。“Einstein repeatedly argued that there must be simplified explanations of nature， because God is not capricious or arbitrary。 No such faith comforts the software engineer。”This book for sure is not for everybody。 It's not a book about programming languages， frameworks or project management。 It's a book about software and why it is hard to build within a budget and available time。 If that's the idea you would like to ponder about you have found a book just for you。 。。。more
Rami Luisto
，
An excellent book on how to manage projects， among other things。 Highly recommended。
Mehmed Duhović
，
A good read and revolutionary at the time， although it is a bit outdated （which is expected from a book written in 1975）。 Still， I could pick up a lot of concepts that I didn't know or didn't understand before。 A good read and revolutionary at the time， although it is a bit outdated （which is expected from a book written in 1975）。 Still， I could pick up a lot of concepts that I didn't know or didn't understand before。 。。。more
Aaron
，
Oof。 This book aged extraordinarily poorly。 There's a number of big problems: the hardware assumptions are completely out of date （sharing of resources that aren't capable of just scaling to need is long over except the most advanced deep learning research， and even that is mostly solved at this point; discussion about how developers need computers with 1MB hard drives; etc etc）， the references to old software and hardware are very very numerous and totally irrelevant， metrics are totally irrele Oof。 This book aged extraordinarily poorly。 There's a number of big problems: the hardware assumptions are completely out of date （sharing of resources that aren't capable of just scaling to need is long over except the most advanced deep learning research， and even that is mostly solved at this point; discussion about how developers need computers with 1MB hard drives; etc etc）， the references to old software and hardware are very very numerous and totally irrelevant， metrics are totally irrelevant， and so on。Organizationally， the idea of the "surgical team" has fallen way out of favor considering it's a lot of people centered on apparently just two decision makers。 I suspect given today's churn this won't work， and besides the unlikeliness of getting a single person that understands any system completely end-to-end is。。。 not likely to happen anytime soon。 It all reeks of "tiger team" stuff; in my experience that results in a toxic culture that doesn't actually solve the problem any more effectively than if you did things more democratically/reasonably。 I do think there's some place for this centralization around a few core lead designers， theoretically， though I doubt that it would work super successfully。Moving on with problems， there's the assumption that waterfall is the only approach to development （I think modern high-quality development is not capable of working in this manner， with a very small set of exceptions）， and a whole lot of discussion on prior design， not really realistic these days at scale， and even if it is， there's a distinct lack of examples to work with。 It's effectively telling us to document everything， with no discussion on what that looks like in his opinion。 Much of the problems of coding these days isn't actually the code but management of disparate pieces of open source libraries， and that hasn't really been considered。A few concepts discussed are correct， but hilariously out of date， proving just how out of date this is。 For example， he takes a stance on if operating systems， programming languages， and naming variables are good things， and that GOTO is a bad idea。 These days these are all taken for granted， maybe not then but regardless the brave show of taking a stance on subjects so obvious now shows that this really isn't relevant today。The one piece of advice that really remains -- that adding more developers to a project slows it down -- is at this point mostly common knowledge， though still often ignored。 So， it has that going for it， at least。I'd give it 2 stars， but I bump it up to 3 on the iffy precedent that it was relevant once upon a time， and it has one piece that's still relevant。 I'd read the first chapter and then stop。 。。。more
Bernardo Lima Carvalho
，